[Datenschleuder] [61]    EC: Auf der Suche nach der PIN

EC: Auf der Suche nach der PIN Gar nicht so richtig vorgesehen war der Wirbel, den eine kleine Demonstration einer der vielen EC-Karten Spielereien vor einem Fernsehsender verursachte. Andreas war bei der "Netznacht" eines großen deutschen Fernsehsenders, und damit es in der langen Nacht nicht so langweilig wird, hatte er auch ein bißchen was zum Spielen mitgebracht (siehe Source Code). Es ging dabei um die praktische Vorführung der schon länger gerichtsverbindlich bekannten Feststellung (siehe DS 59), daß sich die PIN einer "alten" EC-Karte mit der Wahrscheinlichkeit 1:150 erraten läßt, wenn nur die Offsets bekannt sind. Der eigentliche Grund für die Schlagzeilen in den Zeitungen und die Aufregung in den anderen Medien war allerdings gar nicht diese Nachtsendung, sondern ein anschließend gedrehter Beitrag eines unseriösen Wirtschaftsmagazins des selben Fernsehsenders, der in seiner Pressevoraberklärung behauptete, "die PIN-Nummern seien ohne Aufwand und ohne spezifische Kenntnisse zu entschlüsseln [...] Das habe am Wochenende ein Mitglied des Hamburger Chaos Computer Club [...] demonstriert. Von einer Entschlüsselung im Sinne einer Ausrechnung des PIN-Codes kann allerdings nicht die Rede sein, es geht nur darum, die Anzahl der Rateversuche auf eine sinnvolle Anzahl zu reduzieren. Die zugrunde liegende Mathematik lieferte Markus Kuhn schon vor einiger Zeit (siehe nebenstehendes Dokument). Dabei sind 2 Faktoren für die Eingrenzung der (theoretisch 9999) Möglichkeiten verantwortlich. Zum einen die bereits hinreichend (in der Datenschleuder 59) besprochene Umwandlung der internen hexadezimalen Zahlen in Dezimalziffern nach Modulo 10. Zum anderen die 3 Offsets, die für die ursprünglich vorgesehenen 3 Pool-Schlüssel jeder EC-Karte beigefügt waren; sie wurden dem Rechenergebnis der DES-Verschlüsselung von Kontonummer, BLZ und Kartenfolgenummer jeweils für den Pool-Schlüssel hinzugefügt, damit letztlich die selbe PIN wie mit der Verschlüsselung mit dem Institutsschlüssel rauskommt. Inwieweit diese mathematische Spielerei bei den gegenwärtigen PINs noch gilt ist unstrittig, bei den zukünftigen PINs ist es bei derzeitiger Informationslage noch etwas unklar. Noch haben nicht alle Geldinstitute auf neue PIN-Codes umgeschaltet und somit behält auch der Offset 1 noch seine theoretische Möglichkeit. Der Behauptung des Zentralen Kreditausschusses, auch heute seien schon "alle" Automaten "nur" noch im Online-Betrieb kommt dabei nur eingeschränkte Bedeutung zu. Denn ob der Pool-Schlüssel noch benutzt wird oder nicht, ist für einen "Errater" mit allen drei Offsets zunächst mal piepschnurzegal. Er will ja "nur" die PIN. Auch gibt es widersprüchliche Aussagen zur Verbindlichkeit der Aussagen des Zentralen Kreditausschusses. Die Behauptung "alle Automaten sind nur noch online" ist vermutlich eine etwas verkürzte Version von "wir haben beschlossen, daß alle Automaten der bei unserem Verband angehörigen Geldinstitute nach unseren Richtlinien online seien müssen. Wenn sie sich nicht an unsere Richtlinie halten, tragen sie selbst die Haftung für etwaige Auszahlungen, die sie trotzdem gemacht haben". Anders formuliert: der ZKA kann offenbar nur Empfehlungen ausprechen. So wird auf einer ganz anderen Baustelle ja auch gerade versucht, den zunächst einmal totgeborenen deutschen Homebanking-Standard HBCI den Instituten von ZKA-Seite aufzuzwängen; und die spielen da auch nur bedingt mit - weil es Geld kostet und nix bringt. Ein leitender Angestellter einer Bank kommentierte das neulich in einem Hintergrundgespräch so, daß man sich zunächst einmal zurücklehne und gucke, ob sich den HBCI am Markt - vor allem am Softwaremarkt - überhaupt durchsetze. Wenn man tatsächlich HBCI u.a. auch anbieten müsse, bietet man halt zwei Basisfunktionalitäten, die nicht zu teuer sind. Wir müssen also in unserem Bild von der Situation womöglich zwischen den Geldinsituten auf der einen Seite und dem ZKA auf der anderen Seite unterscheiden. Die Institute vermeiden tunlichst, sich zur Unsicherheit der EC-Karte zu äußern, sondern überlassen dies dem ZKA. Ist aus der Sicht der Banken auch verständlich: selbst wenn denen die Geldautomaten nur so um die Ohren fliegen und einer nach dem anderen leergemacht wird, halten sie die Schnauze. Für eine Bank ist der Glaube des Kunden an die Sicherheit der Bank existenziell - nicht die Sicherheit selbst. Auf diese Annahme gestützt, geben ihr ja die Kunden das Geld. Das ist also zunächst mal ganz neutral formuliert das Geschäftsprinzip einer Bank. Die Reaktionen der Kunden auf ein Eingeständnis etwaiger Unsicherheit können nur als katastrophal für die Banken erahnt werden; vor allem, nachdem man sich mehr als 10 Jahre in der Behauptung versteift hat, daß das System sicher sei. Der ZKA ist also als Verband (und somit letztlich Dienstleister) der Banken für die Öffentlichkeitsarbeit in dieser Sache und die technischen Vereinbarungen und Betriebszustände zuständig. Nach außen hin wird professionellstmöglich behauptet, alles sei in Ordnung. Nach innen hin gibt es zwei Problemstellungen: die technische Unsicherheit einzugrenzen und dafür zu sorgen, daß keine Bank in dieser Situtation durchdreht. Der konkrete Fall ist ein gutes Beispiel für die desolate Lage der Banken und des ZKA. Da gibt es zum Beispiel ja den Beschluß das alle Inlandsautomaten online zu sein haben - auch und gerade mit dem "alten" Poolkey-Verfahren und daher die Offsets im Prinzip - und für den inländischen Betrieb - gar nicht mehr auf der Karte sein müssen. Damit wurde auch beschlossen, daß die Offsets bei Benutzung der Karte im Automaten gelöscht werden, damit sie nicht als Angriffspunkt für einen Angreifer dienen können. Na dann ist ja alles gut, oder? Blöderweise geht da so ein CCC-Blag in eine Fernsehsendung und auf der EC-Karte des Redakteurs finden sich - oh' Wunder - alle Offsets. Und was tut der ZKA? Der ZKA kotzt. Aber nur nach innen. Denn nach außen wird er ja dafür bezahlt, gute Miene zu machen. Nach innen hin allerdings muß natürlich dem "verantwortlichen" Institut eins auffe Mütze gegeben werden, dafür, daß es offenbar die "Empfehlung" (Anweisung) ignoriert hat, die Offsets auf der Karte zu löschen. Irgendjemand hat behauptet, genau das wäre passiert. Alles Quatsch? Was die Verwendung der Offset-Felder beim "neuen" PIN-Verfahren "ohne" Poolkey betrifft, ist noch etwas unklar. Zumindest bis zum Congress. Und an der Haftungsfrage wurde natürlich auch nix geändert. Soweit ein bißchen ein Metablick mit eingrenzbaren subjektiven Faktoren. andy@ccc.de offset.c Das nebenstehende Programm zeigt eine einfache Implementierung der statistischen Analyse der Offsets der EC-Karte. Der Aufruf ist offset 0 1234 5678 9012 für alte EC-Karten (die vierstelligen Zahlen sind die drei Offsets) und offset 5 1234 5678 9012 für die neuen EC-Karten. Viel Spaß am Gerät andreas@ccc.de offset.c: /* * offset.c */ #include <stdio.h> int p[15][10] = { { 0, 4, 2, 2, 2, 2, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2, 2, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2, 2, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2, 2, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2, 2, 1, 1, 1, 1 }, { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }, { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }, { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }, { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2, 2, 1, 1, 1, 1 } }; int po(int pin, int offset) { return p[4 + n][(pin + 10 - offset)%10]; } int main(int argc, char* argv[]) { int stelle, stelle2, offset, i; int probdivisor, probdivsum, probsum[4], prob[4][10]; int stellen[4]; double pinprob; n = atoi(argv[1]); for(stelle = 0; stelle < 4; stelle++) { probdivsum = 0; for(i=0; i<10; i++) { probdivisor = p[stelle + n][i]; for(offset = 0; offset<argc - 2; offset++) { probdivisor *= po(i, argv[offset + 2][stelle] - '0'); } prob[stelle][i] = probdivisor; probdivsum += probdivisor; } probsum[stelle] = probdivsum; } for(stelle = 0; stelle<4; stelle++) { for(i=0; i<10; i++) { printf("%f ", (float)(prob[stelle][i]) / (float)(probsum[stelle])); } printf("\n"); } for(stellen[0] = 0; stellen[0] < 10; stellen[0]++) { for(stellen[1] = 0; stellen[1] < 10; stellen[1]++) { for(stellen[2] = 0; stellen[2] < 10; stellen[2]++) { for(stellen[3] = 0; stellen[3] < 10; stellen[3]++) { pinprob = 1.0; for(stelle = 0; stelle< 4; stelle++) { printf("%i", stellen[stelle]); pinprob *= ((float)(prob[stelle][stellen[stelle]]) / (float)(probsum[stelle])); } printf(" %lf\n", pinprob); } } } } }

[Datenschleuder] [61]    EC: Auf der Suche nach der PIN